fnCloseModules in impact_all_recursive.inc

DOORS ships with a standard layout DXL called impact_all_recursive.inc

at

C:\Program Files\IBM\Rational\DOORS\9.6\lib\dxl\layout\actual

In this file the code traverses links to generate a layout display

As the script executes it stores the modules it opens in a top level skiplist.called g_skpLayoutDXLOutLinkModulesOpened

The code finishes with

    if (isLastObjectInDXLSet(obj)){
        // Need to keep skip list of open modules a la suspect links? 
        // Need to close them all once we're done.
        fnCloseModules(g_skpLayoutDXLOutLinkModulesOpened)
    }
    // delete skip
    delete g_skpLinkedObjects

AFAIK normally layout code will open the necessary modules and then leave them open which makes scrolling smooth.

Why is the code closing all the modules if the object is last in the displayset?

As soon as the user scrolls then the modules have to be opened again (and then closed... and then opened again .... and then closed etc.)

This causes the scrolling to be very slow and clunky. The problem becomes especially bad if the client is served via Citrix.

The code is shipped with DOORS as a stock example of how to do things so is the use of fnCloseModules for the isLastObjectInDXLSet object a mistake or is it being used for some reason?

Sean

Re: fnCloseModules in impact_all_recursive.inc
Mathias Mamsch - Tue Dec 01 17:27:10 EST 2015

Well you have to die one death ... Either you dont close the module but eventually run into out of memory problems from a possible indefinite number of opened modules, or you close them and suffer of constant reopening. The only way to get around that is to precalculate all column values, either in a DXL attribute or in a cached layout column. Regards, Mathias

Re: fnCloseModules in impact_all_recursive.inc
DoorsXLAustralia - Tue Dec 01 18:13:23 EST 2015

Hi Matthias,

It would be good to close the modules when the view was changed to another view or when the current module is closed but this code is closing the modules at the end of every screen refresh.

So when the user scrolls the view in the current module the linked modules all have to be re-opened and then closed again.

Surely closing the linked modules while the traceability view is still loaded and fresh trace data may be required is an error?

I think the best approach would be to run fnCloseModules on a close trigger on the current module.

It should maybe be standard close trigger behaviour on all DOORS modules to close all modules in this skip to keep traceability memory under control. But it should not be done inside the trace code while it is still loaded and may be required to generate new trace information.

A customer is experiencing severe performance degration due to trace code which was based on impact_all_recursive.inc

The problem becomes many times worse when viewing through Citrix since the Citrix thin client seems to force DOORS to repaint the traceability columns even when the mouse is just moved over the module display, (i.e. not only when the user scrolls new objects into view).

If fnCloseModules is commented out of the trace code then the performance is good again.

Making it a DXL attribute does not help much in this case since DXL attribute values are only calculated for visible objects and then calculated for new objects as they enter the displayset (I think the documentation suggests that all values are calculated for all objects when the module is opened but I found otherwise by experimentation some years ago). So then the modules are opened, some trace attribute DXL results are calculated, the modules are then closed, the user scrolls, the modules have to be opened and closed again to calculate new trace attribute dxl etc. The only performance advantage will be that objects which have already been displayed once will not be recalculated.

Sean

Re: fnCloseModules in impact_all_recursive.inc
Mathias Mamsch - Mon Dec 07 06:09:54 EST 2015

DXL attributes are calculated for all objects inside the module, usually when the attribute is accessed, e.g. displayed or filtered (sometimes on opening the module). So you will get the performance improvement when you switch from layout to attribute DXL. The disadvantages are:

- Calculation might take ages when you first display the attribute

- Since the calculation of the DXL attributes is done independently for each object and you cannot control the order, you cannot be sure, that you run out of memory, when the script will open all modules.

To be efficient here I suggest you to use the following approach:

- If you don't fear running out of memory, use a DXL Layout, keep the modules open. Try closing them when the script finishes.

- If you fear running out of memory - don't use Attribute DXL or Layout DXL. Precalculate the results, store them in a text attribute. Edit mode is necessary to get up to date data and the user needs to invoke a script.

If you cannot live with any of those:

- Take a look at the Gui cached layout DXL approach I suggested earlier. This will allow you to do background calculation of the data, while the user works in the module.

Regards, Mathias

Re: fnCloseModules in impact_all_recursive.inc
DoorsXLAustralia - Mon Dec 07 08:16:50 EST 2015

Hi Mathias,

Those are interesting suggestions for alternatives to Layout and Attribute DXL.

I am curious about why the DOORS standard code uses fnCloseModules in 8 separate .inc files under

C:\Program Files\IBM\Rational\DOORS\9.6\lib\dxl\layout\actual

The issue is that the function fnCloseModules is used in conjunction with the function isLastObjectInDXLSet(obj). For layout DXL this isLastObjectInDXLSet function returns 'true' for the last object currently visible in the DOORS module window. This last visible object in the window changes as you scroll through the module so the linked modules are repeatedly opened and closed which is very costly in terms of cpu and network bandwidth usage (even if it could potentially keep peak memory usage lower).

The issue gets worse when the Layout DXL is converted to Attribute DXL since the function isLastObjectInDXLSet(obj) returns 'true' for every single object in the module so the linked modules are opened and closed for every single object with links in the current module as the user scrolls.

I was able to get the performance of DOORS modules using custom DXL with isLastObjectInDXLSet + fnCloseModules to go from unusably slow to quite normal simply by commenting out the call to fnCloseModules.

Sean

Re: fnCloseModules in impact_all_recursive.inc
Mathias Mamsch - Mon Dec 07 08:51:08 EST 2015

As I said. Being slow is much better than crashing on memory exhaustion. Lots of customers have links between very large modules. Therefore they introduced the fnCloseModules in DOORS 9.x as far as I remember ... Regards, Mathias